The present invention is generally related to computers and computer programs and, more particularly, is related to a system and method for optimizing the access to shared data.
As is known in the computer and software arts, an executable file is typically composed of several separately compiled object modules and libraries. In the past, all of the code and data necessary to build an executable file was usually linked into one monolithic file. Nowadays, it is more likely that an executable file generated by a compiler and linker will be incomplete, requiring a plurality of shared libraries (or dynamically linked libraries in OS/2 and Windows parlance) and data files. The base executable program is linked together with any dependent shared libraries at load time to produce a complete program.
There are many advantages to the foregoing configuration and technique. In particular, common functionality, such as the standard input/output (I/O) facilities of the C language, for example, can be shared among all of the processes running on the system, rather than requiring that each have its own private copy. When a patch or bug fix is required for a routine within a shared library, the vendor can ship a new library, and all of the programs that depend on the library will automatically pick up the new code the next time they are executed, without the need for recompilation.
For remote code access, such as in a function call, a jump/branch instruction is used to transfer control from one point in the code to another. If the function being called is in a different load module, a new piece of code called the import stub can be used to serve as a local substitute for the real function (i.e. its purpose is to jump to the real function, and that import stub can be patched at load time with the actual address once the second load module has been loaded). Thus, there would be a cascaded jump (i.e. function A jumps to the import stub, which then immediately jumps to function B). Function calls typically accomplish this by using pc-relative (or ip-relativexe2x80x94same thing) addressing. The pc (program counter) or ip (instruction pointer) is the address of the current instruction. Then, the program code can jump from one point in the code to another simply by knowing the relative distance between the two places.
For remote data access, a load or store instruction is used to access an item of data in memory. If the item is in a different load module, an import stub can not be used (i.e., the import stub only works because it actually causes jumping to the import stub and transferring control). When loading or storing data, there is no transferring control to a new code block, the code control stays within the current code. Instead, the only choice is to have the compiler generate code that does an indirect access to the data, unless the compiler knows at compile time that the data will be in the same load module. Unfortunately, the remote data access technique comes with a performance penalty. Code accessing data areas within the same load module can be efficiently done because the complete physical layout of the data area is known at link time. Typically, the accessing code uses global pointer-relative addressing. However, access to remote data (i.e., dynamically-loaded library files) use more time-consuming instruction sequences, because the location of the remote data is not known until runtime.
Normally for function calls, the compiler makes the optimistic assumption that the function called is directly reachable. The import stub is provided at link time if that assumption proves false. However, for data accesses, the compiler makes the pessimistic assumption that the data to be accessed is in a different load module. This policy is necessary because cascaded loads are not possible in most architectures in the same way that cascaded jumps can be used to implement an import stub for a function call.
Heretofore, software developers have lacked a system and method for accessing shared data in a more efficient way.
The present invention provides a system and method for optimizing access of shared data. Briefly described, in architecture, the system can be implemented as follows. The data load optimization system includes a linkage table that contains at least one unresolved data module accessible by a computer program. The data load optimization system also includes a load determination logic that determines the location of the unresolved data module at load time of the computer program, and a load modification logic that modifies the load instruction in the computer program, at load time of the computer program, to directly load the unresolved data module at the location.
The present invention can also be viewed as providing a method for efficiently accessing shared data. In this regard, the method can be broadly summarized by the following steps: (1) generating a linkage table for the computer program when a load instruction in the computer program loads an unresolved data that is not in a same load module as the computer program; (2) determining a location of the unresolved data at load time of the computer program; and (3) modifying the load instruction at load time of the computer program to directly load the unresolved data at the location.
Other features and advantages of the present invention will become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional features and advantages be included herein within the scope of the present invention.